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ABSTRACT 


Current software development methodologies have proven to be ineffective for 
meeting the rising demand for fast production of reliable software for hard real-time 
computer systems. A computer-aided, rapid prototyping system (CAPS) based on a 
Prototype Systein Description Language (PSDL) and a set of software tools including 
an Execution Support System (ESS), has been proposed by other research and provides 
a promising and cost effective alternative to the traditional development life cycle of 
these systems. 

This study proposes a four function design for the dynamic scheduler of the CAPS 
ESS. This design includes a method for invoking processes for the ESS static scheduler 
and translator, a scheduling algorithm for the scheduling of the prototvpe’s non-time 
critical processes, and a method for error and interrupt handling during prototype exe- 


cution. 
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I. INTRODUCTION 


A. BACKGROUND 

Increasing demand for rapid development of high quality software has risen to the 
point that significant improvements must be made to current software development 
methodologies. This is because these methods do not produce software fast enough, nor 
do they result in software products of sufficient quality. This is particularly true for 
development of software for hard real-time systems. A hard real-time system is one in 
which tasks have deadlines that must be met, otherwise severe consequences may result. 
Many Command, Control and Communications (C3) Systems are examples of such 
systems. 

Production of hard real-time systems that support communications requirements 
within the area of C3 are particularly challenging to software developers. One reason 
for this 1s that communications systems are usually subject to very stringent real-time 
requirements. For example, receiving and processing data from remote sensors may 
need to occur in the micro or millisecond timeframe. Another reason, often inherent to 
defense systems, is that communications software (as well as other types of software) 
must be interoperable across a wide variety of hardware and software environments. 
This is exemplified bv the fact that equipment from multiple vendors (utilizing propric- 
tary or incompatible protocols), and obsolete, poorly documented systems must function 
together in support of various operational requirements. Furthermore, maintenance 
considerations across these diverse environiments introduce an additional level of difti- 
culty for software developers because the interoperability of these systems must be 
maintained when inconsistencies are reconciled or when upgrades are applied. 

One method for meeting these challenges, and the increased demand for rapid sys- 
tem development, is rapid prototyping. A prototvpe is an executable model or pilot 
version of the intended system which is used as an aid in analysis and design rather than 
as production software to be delivered to the user. Rapid prototyping is the con- 
struction activity which creates this executable model. This technique has been found 
to be effective for clarifying user requirements and eliminating the large amount of 
wasted effort currently spent on developing software to meet incorrect or inappropriate 


requirements in traditional software life cvcles. [Ref. 1: p. 1] 


Rapid construction of executable prototypes for hard real-time systems would be 
greatly enhanced through the use of a computer-aided design system. One such system 
proposed by [Ref. 2] and [Ref. 3] is the Computer Aided Prototyping System (CAPS). 
CAPS presents an alternative to the traditional software development life-cycle and is 
based on a Prototype System Description Language (PSDL) and a prototyping meth- 
odology. 

The CAPS prototyping methodology, as illustrated bv Figure 1 on page 3 is an it- 
erative process. The software developer constructs a prototype based on user require- 
ments, then the developer and user examine the executable prototype together. During 
this examination, adjustments are made and the prototype is modified until both the user 
and developer agrce that the user's requirements will be met. 

Prototype System Description Language (PSDL.) was developed in conjunction with 
this methodology because a language for supporting rapid prototyping of large real-time 
systems has different requirements from general purpose programming or specification 
languages. PSDL contains several unique features Which meet these requirements. For 
example: 


PSDL is based on a siinple computational model which linuts and exposes the inter- 
action between system modules thus promoting effective modularization of the pro- 
On pe: 


PSDL contains basic data, control, and function abstractions which allow specifica- 
tion and representation of the intended system most important for creation and exe- 
cution of the prototype. 


Appendix A is an example of a PSDL prototype as it appears in (Ref. 4: pp. 27-40) 
and Appendix B is a summary of PSDL grammar and language conventions froin [Ref 
I: pp. 54-56], provided as additional clarification for this exainple. This prototype was 
developed to modei a simple system for treating brain tumors using hyperthermia and 


was structured to meet the following requirements: 


l. Shutdown: Microwave power must drop to zero within 300 milliseconds of turning 
off the treatment switch. 


H 


Temperature Tolerance: After the svstem stabilizes, the temperature must be kept 
between 42.4 degrees C. and 42.6 degrees C. 


3. Maximum Temperature: The temperature must never exceed 42.6 degrees C. 


4. Startup Time: The system must stabilize within 5 nunutes of turning on the treat- 
ment switch. 


3. Treatment Time: The system must shut down automatically when the temperature 
has been above 42.4 degrees C. for 45 munutes. 
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Figure l. PROCESS OF REQUIREMENTS DETERMINATION AND VALI- 
DATION BY PROTOTYPING 


[Ref. 4: pp. 26-27] 
A prototype is created in PSDL using networks of operators communicating via 


data streams. A data stream Is a communications link connecting exactly two operators, 


a producer (one which produces a data value), and a consumer (one wlhucl consumes 
or receives the data value). Data streams also carry data values wiuch represent EX- 
CEPTION conditions. PSDL exceptions are values of a built in abstract data type called 
EXCEPTION. This type has operations for creating an exception with a given name 
(e.g. “overflow”), and for detecting whether a value is normal (1.c. belongs to some data 
type other than EXCEPTIOSA CAN 

The other PSDL data types include the unalterable subset of the built-in types of the 
Ada® programming language (Ada® is a registered trademark of the United States 
Government, Ada Joint Programming Office), user defined abstract types, the special 
type TIME (the other special type being EXCEPTION as previously described), and tlie 
types that can be built using the immutable type constructors of PSDL. The PSDL type 
constructors were chosen to provide powerful data modeling facilities with a small set 
of semantically independent structures. [Ref. 4: p. 15] 

Each data type or operator is either composite or atomic. Composite operators are 
implemented by decomposing them into networks of more primitive operators (using 
PSDL). Atomuc operators are created by retrieving an implementation from a software 
base containing reusable software components implemented in an underlying program- 
ming language. 

[n in order to meet timing constraints of the prototype under construction, an op- 
erator can either be periodic, or sporadic. A PSDL operator is periodic if a period has 
been specified for it explicitly, or if it inherits a period from a higher level in the de- 
composition of the hierarchical prototype. If neither of these conditions are true, then 
the operator is sporadic or data driven. A sporadic operator is executed (triggered by) 
the arrival of a new data value, possibly at irregular time intervals, whereas periodic 
operators are triggered or executed at regular time intervals (specified periods). A perl- 
odic operator must be completed sometime between the beginning of the period and a 
deadline (which defaults to the end of the period). Periodic operators have traditionally 
been the basis for the design of most real-time systems, but the importance of data 
driven operators for this type of system is also beginning to be recognized since event 
driven in terms of informal software design methodology, or interrupt driven in terms 
of hardware language, can be treated in this category. [Ref. 4: pp. 6-13] 

The foregoing features make PSDL particularly appropriate for real-time system 
design. Its structure is highly suitable for multiple modifications during prototyping it- 


erations because it consists of basic building blocks that allow descriptions of ab- 


stractions through a top-down design based on data flow. Additionally, the formal 
structure of PSDL for specifving the user’s real-time constraints provides a basis for 
automating the production code to an underlying programming language e.g. Ada®. The 
execution of the PSDL prototype also verifies that the design of an embedded system (a 
system that is part of a larger system such as a guidance computer on a nussile), within 
given timing constraints for the prototype components, will interact with its environment 
in a Way that meets the timing constraints of the entire system. [Ref. 1: p. 3] 

The other components of the CAPS are user interfaces, including a syntax directed 
editor with graphics capability (for speeding up design entry and preventing syntax er- 
rors), an execution support system for demonstrating and measuring prototype behavior 
and for performing static analyses of the prototype design, a software design manage- 
ment system for retrieving and adapting reusable software components, and a compo- 
nent base which functions as a repository for the reusable components [Ref. 2: p. 9]. 
The reusable software components in the software base can be written in any general 
purpose programming language (provided that PSDL specifications for each module are 
included). Figure 2 on page 6 illustrates the CAPS architecture. 

For purposes of simplification, and because of its required use within the Depart- 
ment of Defense as a standard development language, Ada® has been chosen for imple- 
menting both the reusable components in the software base aud the PSDL execution 
support environment. Ada® is a powerful prograniming language that provides unique 
features not found in other languages. These include exception handling, inter-task 
communication, (both of which will be demonstrated to be particularly important to the 
CAPS execution support environment), and facilities such as generic packages (reusable 
software components). Several predefined generic units are already included as part of 
the Ada® language definition e.g. CALENDAR which can be used to provide date and 
time information. (Ref. 5: pp. 33-34) 

An Ada? program is composed of one or more program units, most of which may 
be separately compiled. Program units consist of subprograms, tasks, packages, and 
generic units. A subprogram is either a procedure or a function. A procedure specifies 
a sequence of actions and 1s invoked by a procedure call statement. A function specifics 
a sequence of actions and also returns a value called the result; therefore a function call 
is an expression. A task, on the other hand, defines an action that is logically executed 
in parallel with other tasks. A task may be implemented on a single processor, a multi- 


processor, or a network of computers. A package is a collection of computational re- 
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sources, which may encapsulate data types, data objects, subprograms, tasks, or even 


other packages. lts primary purpose is to express and enforce a user's logical ab- 


Stractions within the language. A generic unit is a “template” or “pattern” for subpro- 
grams and packages and serves as the primary mechanism for building reusable software 
components. Use of a generic unit within an Ada® program is termed instantiation. 

All Ada® program units generally have a similar two-part structure, consisting of a 
specification and a body. The specification identifies the information visible to the client 
(interface) of that program unit and the body contains the unit implementation details. 
Ber. 5: pp. 55, 354) 

Ironicallv, it is some of these same attractive features of the language that make Ada® 
too complex and hence, too impractical, for its direct use in the rapid prototyping envi- 
ronment. PSDL however has incorporated many of the desirable features of Ada® while 
eliminating the associated complexity. The abstractions of PSDL allow a system de- 
signer to express ideas at the specification and design level rather than at the prograin- 
ming language level. This substantially reduces the need for consideration of lower-level 
details and flow control that would be required if the prototype was developed using Ada® 


directly. 


B. OBJECTIVES 

The primary focus of this study is the conceptual development of one component 
of the execution support system of the CAPS, the dynamic scheduler. As it is currently 
proposed, the execution support system will be comprised of three components, a 
translator, a static scheduler, and a dynamic scheduler. The translator is developed in 
[Ref. 6] and the static scheduler is developed in [Ref 7] and [Ref. 8]. A secondary, but 
equally important focus is the interfacing of the dynamic scheduler with these other two 
components. 

Within the CAPS execution support environment each of these components will 
perform several functions as shown in Figure 3 on page 8. The translator has four main 
purposes: 

O augment the PSDL code 


o implement PSDL data streams 


u) 


. To implement PSDL conditionals (triggering conditions) 


4. To implement PSDL timers (accomplished through the use of a standard library 
package which communicates with a hardware clock and is included in any proto- 
tvpe that uses timers) 
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Figure 3. COMPONENTS OF THE CAPS EXECUTION SUPPORT SYSTEM 


The static scheduler analyzes the real-time constraints declared in the PSDL prototype 
and attempts to find a static schedule meeting the constraints of the time critical opera- 
tors of the prototype under construction. 

The dynamic scheduler performs four major functions for the CAPS execution sup- 
port system. The first function, which is to act as a “run-time executive”, 1s of particular 


importance to the other two CAPS components. As the run-time executive, the dynamic 


scheduler will invoke the static scheduler, and it will invoke buffer pre-louding proce- 
dures required by the translator for implementation of data streams. Two other func- 
tions include exception handling and hardware or operator interrupt handling that may 
occur during prototype execution. 

The fourth and perhaps most important function of the dynamic scheduler will be 
the scheduling and execution of the PSDL operators which are not time critical (1.e. do 
not have real-time constraints). This schedule will be constructed and executed during 
prototype execution using “spare processing time” created as a result of early completion 
of time critical operators by the static sclieduler. Because PSDL assumes that time 
constraints of critical operators are absolute when given, the static scheduler allocates 
processing resources based on worst case or maximum execution times. On the average, 
these worst case processor loads tend to be rare. When a time-critical operator or group 
of operators finishes executing before this worst-case tune allocation, the static scheduler 
can “transfer” control of processor resources to the dynanuc scheduler in order to utilize 
the resulting spare capacity. 

The requirement for explicitly passing control to the dynamic scheduler when the 
static scheduler reaches an idle state is necessary because the Ada® language does not 
have features for determining when a task or process with an undefined prioritv should 
be executed [Ref. 5: p. 282]. Once control of processing resources is passed to the dy- 
namic scheduler, spare processing capacity can be allocated among the non-time critical 
operators based on a scheduling process that is not restricted by the requirement for 


meeting real-time constraints. 


C. BENEFITS OF THIS STUDY 

The benefits to be derived from this study are twofold. The first of these is that 
development of a dynamic scheduler for the proposed CAPS aids in meeting the need for 
development of a rapid prototyping tool. An effective CAPS would result in significant 
improvements and cost savings in the development of hard real-time software systems 
which support C3 mission requirements as well as software development for other DOD, 
and private industry applications. 

The second benefit is the focus placed on more effective processor utilization as a 
result of scheduling non-time critical tasks or processes during slack or spure processing 
periods. Previous research in the area of real-timne system scheduling has greatly em- 
phasized, and rightly so, the requirement for meeting the real-time constraints of a sys- 


tem or network of systems. This particular emphasis has minimized the importance of 


processor under-utilization which often occurs as a result of ensuring that real-time 
constraints are met. The problem of under-utilization is wasteful and could become 
quite costly if it is allowed to occur on a regular basis. Design and interface of a dy- 
namic scheduler for use within the rapid prototyping environment may provide a viable 
solution to this problem. 


D. OVERVIEW 
The remainder of this study is described by the following overview: 
A survey of the background and development of scheduling problems and algorithms 


Development of a dynamic scheduler based on concepts provided by this survey and 
the use of Ada® as an implementation language 


A summary which describes the questions answered by this study, future questions or 
design areas that need to be addressed, and a brief description of a communications 
svstem for demonstrating the feasilibity of the CAPS as a computer-aided design tool. 
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Il. BACKGROUND AND DEVELOPMENT OF SCHEDULING 
ALGORITHMS 


A. THE SCHEDULING PROBLEM 

A scheduling algorithm provides a set of rules that determine a process or group of 
processes to be executed at a particular point in time on a process control computer 
system or for a network of systems [Ref. 9: p. 194]. Criteria which have historically been 
used to generate process schedules include maximizing process flow (1.e. minunizing the 
elapsed time for the entire processing sequence), or minimizing the maxunum lateness 
(lateness is defined to be the difference between the time a process is completed and its 
deadline when the deadline is missed) (Ret. 10: p. 112). 

Development of an algorithm which focuses on maximizing process flow is applica- 
ble to the problem of scheduling PSDL operators without real-time constraints since 
Optimal use of idle processing time is an objective of the CAPS dynamic scheduler. 
However, minimizing lateness is not a consideration for the dynamic scheduler since 
operators which are not time critical don’t have deadlines to meet. For meeting the re- 
quirements of the CAPS static scheduler, neither of these criteria 1s important partic- 
ularly since operators with real-time constraints are by definition not allowed to be late. 
The criteria which are important for process scheduling within the CAPS execution 
support environment include meeting the deadlines of operators with real-time con- 
Straints, ensuring that no data loss occurs, and making optimal use of spare processing 
resources. Clearly, finding or developing scheduling algorithms which optimize this sct 
of criteria presents an interesting and difficult problem. 

Another previously defined [Ref. 9: pp. 194-199] consideration for generating process 
schedules and developing scheduling algorithms is based on precedence or priority of 
processes to be executed. Two primary priority classifications are static priority and 
dynamic priority. In the first case, priorities and start times of processes are known in 
advance and is not expected to change during execution [Ref 9: p. 194]. Within the 
CAPS, a scheduling algorithm based on a static priority scheme will be used by the static 
scheduler to create a schedule that meets the timing and precedence relationship re- 
quirements for the time critical operators. In the second case, priorities of processes 
change from time to time, depending upon certain execution conditions (e.g. the avail- 


ability of idle processing capability) [Ref 9: p. 194]. This priority scheme will be used 


ki 


by the CAPS dynamic scheduler to schedule non-trme critical PSDL operators and to 
perform other functions during prototype execution such as exception or interrupt han- 


dling. 


B. SCHEDULING METHODS 
The requirement for different types of schedulers and scheduling algorithms has been 
examined in a myriad of research. Most of this work has been directed at the problem 
of scheduling processes or operations which must meet critical or real-time deadlines, 
but these efforts also have relevance to the problem of scheduling processes which don't 
have real-time constraints. The primary reason for this is that while an individual 
process (e.g. a PSDL operator) may not have a time critical deadline, scheduling of the 
process or group of processes should be completed witliin a predetermined block of idle 
processing time in order to make optimal use of this spare capacity. The following ex- 
amination and description of scheduling research provides a basis for designing a dy- 
namic scheduler to meet this objective. 
1 DECOMPOSITION STRATEGIES 

A primary consideration in solving the scheduling problem 1s how to decompose 
a set of operations (computations) into a schedule which meets the real-time constraints 
of a given system or program. Mok in[Ref. 11: pp. 125-133] proposes three strategies 
for the decomposition of a set of computations based on tuning constraint specifications. 
Each of these strategies uses a “graph” model to describe the set of computations and a 
“process” model to describe the output generated by the translation of the set of com- 
putations. 

The graph model consists of a communications graph, a task graph, and a set 
of tuming constraints. Timing constraints are represented by the expression (t, t + d) 
where t is the start time for a process, d is its deadline, and t + d the interval or period 
in which the process ıs executed. A task graph defines the precedence relationship 
among computational events that must occur in order to satisfy a given timing con- 
straint. Itis composed of “nodes” and “edges” which respectively denote corresponding 
functional elements and transmission paths for data in the communications graph [Ref. 
11: p. 126]. The objective of this structure is to ensure that data flow requirements are 
met. This is also one of the objectives of the PSDL structure, (the other objective being 
that real-time constramts will be met). PSDL is based on these concepts with an oper- 


ator representing a “functional element” of the language, and with data streams repres- 


enting communications paths which transmit or exchange information between 
operators. 

The Process Model is generated by the translation of the time-critical compu- 
tation requirements of a real-time system. The result of the translation is a set of time- 
critical concurrent processes [Ref. 11: p. 125]. The translation that results in the process 
model is analogous to the generation of the of the CAPS static schedule since this 
schedule provides the means for meeting a systern’s real-trme constraints. 

Based on these concepts, the first strategy to be discussed is Decomposition by 
Critical Timing Constraints. This strategy works in the following manner. For a partic- 
ular program, periodic and sporadic processes are created to meet giyen tuming con- 
straints. The perrod and deadline attributes of a process are set to the corresponding 
parameters of the timing constraint (t, t + d). These processes may have functional el- 
ements in common so a monitor is created to ensure mutual exclusion on the execution 
of any program element called by two or more processes. When a program created ın 
this manner is executed, each process is executed according to its specified timing con- 
straints even though this may result in duplicate execution of certain computational 
Events. IRef:11:; p:128) 

This strategv works fairlv well on single processor with anv scheduling discipline 
as long as the processor doesn’t idle while there is an activated process [Rel. 11: p. 128). 
The disadvantages associated with the use of this strategy are the duplication of some 
computations within processes that have compatible timmg constraints and the com- 
munications costs involved for enforcing mutual exclusron. 

A second strategy, Decomposition by Centralized Concurrency Control works 
in the following way. Periodic timing constraints that are compatible with one another 
are grouped together. Two periodic timing constraints are compatible if their deadlines 
(d) are equal, (e.g. dl = d2), if their task graphs have some nodes in common, and if the 
period (p) of one can divide, or be divided by the period of the other (pl/p2 or p2/pl). 
The compatibility relation partitions the periodic tinung constraints into a set of equiv- 
alence classes. For each equivalence class, a periodic process of compatible periodic 
timing constraints is created, and a sporadic process ıs created for each asynchronous 
timing constraint. 

In general, this strategy improves efficiency two ways. First, by merging the 
computation ol compatible timing constraints into a single process, redundant compu- 


tation can be eliminated. Second, since concurrency control is being centralized, proc- 
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esses tend to be independent of one another and the interprocess communication 
overhead required for concurrency control will be smaller. One disadvantage associated 
with this strategy is that attempts to merge compatible timing constraints into a single 
program by eliminating as much redundant computation as possible, may not yteld the 
shortest program possible. A second disadvantage associated with this strategy 1s its 
complexity, which makes it more difficult to understand and to modify when changes 
are required. (Ref. 11: pp. 129-130] 

The third strategy is Decomposition by Distributing Concurrency Control. In 
this strategy, a periodic process will be created for each node (functional element) in the 
communication graph. Since a functional element F, may occur in two or more task 
graphs, the periodic process created for F will be assigned a period attribute equal to the 
smallest period among the periodic timing constraints in which F occurs. When a perl- 
odic process PF, 1s activated, 1t first synchronizes with an appropriate set of processes 
preceded bv it. A sporadic process is created for each asvnchronous timing constraint 
as before. If a functional element occurs in both a periodic timing constraint and an 
asynchronous timing constraint, then a monitor is created to enforce mutual exclusion 
on the execution of the corresponding program element. [Ref. 11: p. 131] 

Use of this strategy results in the following advantages. By assigning a separate 
process to each functional element, an attempt is made to maximize the computation 
that can be performed in parallel. Redundant computation is reduced since task graphs 
of compatible timing constraints that contain the same functional elements are detected 
in the cor.struction of the synchronization code for each periodic process, If as many 
processors are available as there are processes, then this strategy can accommodate a 
wider range of tuning constraints than the other two strategies. The primary disadvan- 
tage with this approach is again onc of complexity and the resultant modification diffi- 
Cities its use unplies (Rett pt. 

2. THREE PROCESS MODELS 

Another study by Mok [Ref. 12: pp. 5-17] develops three process models using 
various scheduling algorithms and techniques. These models are based on the idea that 
there is a need for an off-line scheduler and a run-time scheduler for meeting the periodic 
and sporadic timing constraints of most real-tune systems. ss defined by this work. the 
oll-line scheduler examines the instance of a process, or system and creates a run-time 
scheduler together with a database for making scheduling decisions at run time. The 


run-time scheduler is the code for allocating resources in response to requests generated 


at run time, e.g. timer or external device interrupts. A run-time scheduler is totallv on- 
line if its decisions do not depend on prior knowledge of the future request-times of the 
processses. A run-time scheduler can also be clairvoyant, which ineans that it can pre- 
dict with absolute certainty, the future request times of all processes. A clairvoyant 
scheduler represents the best possible case though and is usually impossible to imple- 
ment in practice. And finally, a run-time scheduler is optimal if it always produces a 
feasible schedule whenever it is possible for a clairvovant scheduler to do so. 

The first model described by this piece of research is the Independent Process 
Model. It was shown that two possible algorithins provided effective scheduling tech- 
niques for this model, the earliest deadline algorithm and least slack algorithm. The 
earliest deadline algorithm runs any ready process with the nearest deadline and the least 
slack algorithm runs any ready process which has the least slack time available before 
it will miss its current deadline. In both cases, ties are broken arbitrarily and the as- 
sumption is made that the scheduler can choose to preempt a process by any other ready 
process at integral time instants. 

Although both of these algorithms are effective, the preceding assumption 1l- 
lustrates why neither of them represents an optimal scheduling method. In order for 
these techniques to be optimal, the scheduler would have to be clairvoyant. For exam- 
ple, the position of an aircraft is updated by a periodic process which computes the X 
and Y coordinates from sensor measurements. A sporadic process may read the X value, 
be preempted by the tracking process, and then read a new Y value which is inconsistent 
with the original X value. Clairvovancv implies that an exact prediction could be made 
as to when the sporadic process which updates the X value will occur, which is unlikely. 
A possible means for eliminating this inconsistency is to prevent processes from pre- 
empting one another, but enforcement of such a mutual exclusion constraint results in 
significant decreases in processing efficiency. [Ref. 12: p. 7] 

A feasible, yet still not optimal, alternative to this approach is provided by the 
Deterministic Rendezvous Model. This model attempts to alleviate the problems asso- 
ciated with the Independent Process Model by using the earliest deadline algorithm with 
dvnamicallv assigned (determined during execution) process deadlines, and through the 
implementation of an Ada®-like rendezvous primitive (communications instruction). 

The rendezvous primitive establishes synchronization and precedence relation- 
ships among executing processes. It operates on the same principle that is required for 


the establishment of certain data communications links. For example, if Process A 
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wishes to communicate or rendezvous with Process B, A executes a rendezvous primi- 
tive. A must then wait for B to execute a rendezvous which indicates that it is ready to 
exchange information or rendezvous with A. The precedence relationships amoug 
processes are created by the requireient that all the computation before the rendezvous 
primitive in each process must precede all the computation after the corresponding ren- 
dezvous primitive in the other process [Ref. 12: p. 9]. 

At run-time, this model works in the following way. Processes are grouped into 
scheduling blocks with each block initialized with a deadline. During execution, the 
deadline of a scheduling block can be inoved up if the block must precede another block 
which has a nearer deadline but whuch is not yet ready to run. The rendezvous primitive 
provides the required synchronization and precedence information which allows this 
scheme to work. It should be pointed out though that this primitive does not guarantee 
mutual exclusion for a scheduling block. It also cannot be used to establish communi- 
cations between a periodic process and a sporadic process since by definition, a periodic 
process must be executed regularly while a sporadic process may never be executed. 
[Ref 12> pp. 9210) 

The third model differs only slightly from the Deterministic Rendezvous ap- 
proach. This model called the Kernelized Monitor, uses an operating system kernel as 
a monitor for enforcing mutual exclusion of processes during execution. Processor tune 
is allocated only in uninterruptible quantums, sav of size q, with q chosen to be bigger 
than the largest monitor. For simplicity, the required computation times for process 
scheduling is in exact multiples of q so that each process takes an integral number of 
quantums to execute. A process to be executed forms a chain of mini-scheduling blocks 
each of which requires a quantum (the basic tune unit of processor allocation). These 
muni-scheduling blocks form a partial order imposed by the (intra and interprocess) 
precedence relationships and each is given a request-time and deadline. The ininl- 
scheduling blocks are executed using the earliest dynamic deadline algorithm as previ- 
ously described in the discussion of the Deterministic Rendezvous Model. 

One difference between the execution of mini-scheduling blocks and the exe- 
cution of blocks created by the Deternunistic Rendezvous approach is that preemption 
Should onlv be allowed to occur after a mini-block has been allocated an integral number 
of time quautums. Another difference is that between each chain of mini-scheduling 
blocks an interval called a “forbidden region” is included in in the schedule. The purpose 


of this interval is to create idle processing time during Which a scheduler should not al- 
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locate a new quantum of processor time to any process so that a future deadline can be 
met Rel 12: pp. 10-11] 
3. EARLIEST DEADLINE-PREDECESSOR PRIORITY ALGORITHM 

Another research effort by Mok demonstrates the use of the earliest deadline 
algorithm in a slightly different way. This effort was directed at periodic real-time sys- 
tems where input data arrives at fixed rates, but otherwise there are no explicit tining 
constraints. Its application is also limited to uniprocessor environments. 

The Earliest Deadline-Predecessor Priority (ED-PP) scheduling procedure can 
be described by these steps. First, a very simple method (as coinpared to use of thie 
rendezvous primitive) 1s used to determine precedence relationships among processes. 
Specifically, processes are ranked in a topological order of their corresponding functional 
elements in a graph model such that whenever two processes have the same deadline, 
higher priority is given to the process which appears earlier in the topological ordering 
(hence the name predecessor priority) [Ref. 13: p. 184]. Next, a round robin scheduler 
is eniployed in the following way. Assume that a quantum (the previously defined tune 
unit) 1s composed of infinitely many slices. A round robin scheduler allocates c/p slices 
of each quantum to each process P. Each P will be guaranteed to receive c quantuins 
of processor time in every period of length p, thus mecting its deadline. The above al- 
location can always be done because available processor time U is < = 1. (Ref. 13: 
p. 186] 

The round robin schedule is then transforined into the desired sehedule by 
swapping time slices in the following manner. At any quantum, let P be the process witli 
the nearest deadline as chosen by the ED-PP scheduler. Then, swap as mauv slices of 
P from the next quantums as needed to (ill just the quantum under consideration. No 
process will miss its deadline since the deadline of p is the nearest. This swapping is re- 
peated one quantum at a time from the beginning of the schedule until the valid ED-PP 
schedule of desired length is obtained. [Ref. 13: p. 186] 

4. IHE RATE MONOTONIC SCHEDULING ALGORITHM 

This algorithm works in the following way. For a set of periodic tasks, a fixed 
priority is assigned to each task, with a higher priority being assigned to tasks with 
shorter periods. The rate monotonic algorithim is an optimal static priority algorithm in 
a uniprocessor environment with a set of n tasks with total utilization less than or equal 


to n(2'"— 1), When n becomes large, this bound approaches In 2 (approximately 70%). 


One inethod for implementing this algorithm incorporates a “time-division 
multiplexing” scheine to schedule periodic tasks (processes). This approach ts similar to 
the round robin scheduler used by the ED-PP algorithm. This 1s accomplished through 
the creation of a set of time division multiplex (TDM) slots and then “hand-packing” all 
the important tasks into them. This is typically done in the context of a cyclical execu- 
tive (the cyclical executive operates like tlie round robin scheduler), which generally uses 
few frequencies. The fastest cycle is usually called the major cycle and the slower ones 
are called minor cycles. The major cycle is assigned the highest priority. Given the 
highest priority, a major cycle with period P will be regularly given 1 slot everv P units 
of tune. This in effect creates a virtual processor with processing bandwidth 1/P. The 
period of the major cycle is determined by two factors. First period P must be short 
enough so that ıt can accommodate the highest frequency periodic tasks. Second, the 
major cycle must also accommodate tasks which have lower frequencies but are critical 
to the mission at hand, since the major cycle has the highest prionty. A handcrafted 
table is then constructed to schedule both the high frequency tasks and the critical tasks 
over the virtual processor. The construction of the scheduling table often takes many 
iterations, over the adjustment of the period of the major cycle, the modification of the 
scheduling table and the optimization of the code of certain tasks. [Ref. 14: pp. 184-185] 

Usmg another approach, this algorithm can be employed to schedule aperiodic 
(sporadic) tasks. Aperiodic tasks consist of a stream of jobs arriving at the processor 
according to some random process such as the Poisson process. In this case, there is 
no deterministic upper bound on the worst case processor utilization task even though 
each job of an aperiodic task has a bounded worst case execution time. Thus, it is im- 
possible to guarantee that every job's deadline in an aperiodic task will be inet. The 
concept behind dealing with aperiodic tasks 1s to reserve adequate processor time [or 
each group of tasks so that fast average response tune can be ensured. 

A simple way to realize this objective is to create a set of periodic tasks, each 
of which serves a group of aperiodic tasks. Each of these server periodic tasks will be 
run according to the basic principle of the rate monotonic algorithm. Associated with 
each server periodic task, there is a ready queue for associated aperiodic jobs. Each of 
these aperiodic jobs in the associated ready queue will be treated as if it 1s a periodic job 
of the server periodic task and dispatched accordingly. Thats , if a periodic server has 
period P and nominal computation time C, then the associated aperiodic job can be ex- 


ecuted C time units in every period P at the priority level associated with period P, The 
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ration C/P represents the processor time allocated for associated aperiodic tasks. |Ref. 
14: p. 183] 
5. “NEXT-FIT-M” 

NEXT-FIT-M is better classified as a decomposition strategy than a scheduling 
algorithm. It was developed for use in conjunction with the rate-monotonic algorıthm 
in a multi-processing environment. The requirement for this strategy is based on the fact 
that the rate-monotonic algorithm behaves poorly in multiprocessor systems if the rule 
is followed of not allowing a processor to idle when there is a task ready for execution. 


NEXT-FIT-M is based on the following assumptions: 


I. Tasks are time-critical and the requests of each task are periodic, with a constant 
interval between tasks. 


2. Deadlines consist of runability constraints only, 1c. each request must be com- 
pleted before the next request of the of the same task occurs. 


3. The tasks are independent in that the requests of a task do not depend on the ini- 
tiation or the completion of the requests of otlier tasks. 


4. Computation time for the requests ofa task is constant for the task. Computation 
time here refers to the time a processor takes to execute the request without inter- 
ruption. 


5. Task utilization is defined by two numbers, the computation time of the request(c), 
and the request period(t). The ratio ct is called the utilization factor of the task. 
(Ref. 9: p.194) 

In a multiprocessor environment, this utilization factor provides a means for 
decomposing tasks into classes. A class is defined for each available processor in the 
system, and tasks belonging to a given class are scheduled on the processor with the 
appropriate class designation. Task classes are created based on a range of utilization 
factors e.g. class A tasks have utilization factors between .4 and .l, class B tasks range 
between .2 and .4, etc.. Actual utilization ranges are established using a logarithmic 
scale derived from the formula (2/7 — 1) as described bv [Ref. 9: p. 195]. When de- 
composition and assignment of task classes to processors is complete, execution pro- 
ceeds on each processor according to the rate-monotonic algorithm. 

6. A TIME-DRIVEN SCHEDULING MODEL 
Another approach to scheduling 1s illustrated by the Time Driven Scheduling 

Model and its two associated algorithms, BEValuel and BEValue2. (Ref. 10: pp. 

112-122] This model is based on a linear mathematical function. The concept of in- 

creasing or decreasing linearity is used to describe the precedence relationship among a 


set of processes. The input for the model is a set of preemptible processes P, resident in 


a computer with a single shared memorv and one or more processing elements. Each 
process P has a request time R, wuich is an arbitrary time at which P has been requested 
to be executed and a processing or computation time, C. [or each P, a value function, 
V(t) is created where t is a time for which a value is to be determined and V defines the 
value to the system for completing P at time t. The nature of V is determined by which 
scheduling algorithm is used, BEVatuel or BEValue2. 

These two algorithms take advantage of three value function and scheduling 


characteristics: 


l. Given a set of processes (ignoring deadlmes) with known values for completing 
them, 1t can be shown that a schedule in which the process with the highest value 
density V/C, (in which V is its value and C is its processing time as previously de- 
scribed) is processed first will produce a total value at every point in time at least 
as high as any other schedule. (i.e. a Value Density Schedule) 


th 


Given a set of processes with deadlines which can all be met (based on the sequence 
of the deadlines and the computation times of the processes), ıt can be shown that 
a schedule in which the process with the earliest deadline is scheduled first (1.e., an 
Earliest Deadline schedule) will always result in meeting all deadlines. 


3. Most value functions of interest have their highest value occuring immediatelv 
prior to the critical time. 
The BEValuel Algorithm exclusively uses observation | above, and is therefore 
a simple greedy algorithm, scheduling first the process with the highest expected value 
density. It has been shown that this algorithm performs reasonably well in many cases 
in Which the value function is a step function, or if the function is rapidly decreasing 
following the critical time, inspite of the fact it makes no use of critical time itself. The 
critical time does, of course, enter the algorithm through the expected value computa- 
tion, which uses the value function and the assumed processing time distribution to 
compute an expected value. It was also shown by experimental results, that this algo- 
rithm fails most notably in step function situations where processor loads are low or at 
an average level, and a nuinber of processes with close deadlines are in the request set. 
The BEValue2 algorithm attempts to rectify this situation by the implementa- 
tion of the following modification. This algorithin starts with a deadline-ordered se- 
quence of available processes, which is then sequentiaily checked for its probability for 
overloading the processor. At any point in the sequence in which the overload proba- 
bility passes a preset threshold, the process prior to the overload condition with the 
lowest value density, will be removed from the sequence. Tlis process is repeated until 
the overload probability reaches an acceptable level. Because of this modification, this 


algorithm tends to out perform BEValuel since it always meets deadlines as long as no 


processing overload occurs. However, when an overload condition occurs and gradually 
worsens, performance of this algorithm 1s similar to BEValuel. [Ref. 10: p.116] 
7. DYNAMIC SCHEDULING OF TASK GROUPS 

A more complex, yet extremely useful approach to process scheduling is de- 
scribed by [Ref. 15: pp. 166-174]. This research examined the problem of dynamic 
scheduling for groups of tasks in distributed real-time systems. The scheduling algorithm 
developed to meet this requirement is broken down into several smaller algorithms, a 
pre-processing algorithm, a distributed scheduling algorithm, and a compression algo- 
rithm. 

The pre-processing algorithm divides processes into clusters and computes the 
required time to execute each cluster. Clusters are ordered into a precedence relationship 
based on these computations. This ordering is somewhat arbitrary and can be modified 
(through the the use of the compression algorithm) if necessary. Processes within a 
cluster are ordered according to real-time constraints by a ınethod similar to that de- 
scribed by the earliest deadline approach. Based on this computation, this algorithm 
makes the decision whether or not there is enough processing time available to schedule 
a cluster of processes. If there is, a “dispatcher module” begins or enables the execution 
of the cluster. 

Once a cluster begins executing, due to precedence constraints, processes within 
the cluster must synchronize in real-time in order to communicate with one another. 
When one process finishes executing, it sends an enabling message, as Well as output 
data, to a successor process (the one which is next in the precedence ordering). A suc- 
cessor process can begin execution only after the enabling message from its predecessor 
has been received. Another module called the inter-task communication haudler, is in- 
voked each time a process finishes execution. This module evaluates incoming enabling 
messages and updates the number of finished predecessor processes when more than one 
is required for the execution of a particular successor task, and it sends enabling mes- 
Sages to successor tasks. 

In the instance of a distributed system, the distributed scheduling algorithm is 
invoked when there is not enough processing time available to successfully execute a 
cluster. This algorithm attempts to find another location in the svstem for the cluster 
KoNbe exccuted. 

When it appears that a cluster cannot be successfullv executed at anv location, 


the compression algorithm is invoked. Because the computed execution time for a 
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cluster is only an estimation, this algorithm is designed to compress the execution time 
for the entire cluster, or for individual processes when possible, within the cluster. [Ref. 
IS ppal Toon 
8. A RECEIVER-INITITATED SCHEDULING STRATEGY 
Another scheduling method is described in a comparison-oriented piece of re- 
search. Chang and Livny [Ref. 16: pp. 175-180] examined Sender-Initiated and 
Receiver-Initiated scheduling strategies in a multiprocessor environment. The 
Receiver-Initiated approach is of primary interest and works in the following way. Upon 
the completion of a job (process) the load of the processor is examiied to deterimine if 
itis underloaded. When the number of jobs left in the queue is smaller than some preset 
threshold, the processor is tagged as underloaded. When this condition occurs, the 
underloaded processor polls other processors in the system to offer “help” (1.e. processing 
resources). This technique was proven to be an effective method for sharing and dis- 
tributing resources among processors in a multi-processing environment. The basic idea 
appears to be a reasonable approach for sharing resources among processes as well. 
9. APPLICATIONS OF THESE METHODS FOR THE CAPS SCHEDULERS 
The foregoing scheduling methods were described to provide background infor- 
mation on the development of scheduling techniques and also to provide a basis for the 
development of the CAPS dynainic scheduler. Some of the techniques are also useful 
for describing the operation of the CAPS static scheduler and how the static and dy- 


namic schedulers will interact in the execution support environment. 


to 
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WW. THE CAPS DYNAMIC SCHEDULER 


A. SCHEDULING FUNCTIONS 

Within the CAPS execution support system, the dynamic scheduler will perform se- 
veral functions. First, it will act as the “run-time” executive that invokes, or starts the 
static scheduler and buffer preloading procedures for the translater. Second, it will cre- 
ate and invoke a schedule for the non-time critical operators of the PSDL prototype, 
third it will handle exceptions (both defined and undefined types) for all of the the CAPS 
components, and fourth it will handle both hardware and operator interrupts that may 
occur during prototype execution. These functions are illustrated by Figure 4 on page 
24. 

The proposed operation of the dynamic scheduler is outlined by the hierarchal de- 
scription included as Appendix C. This design is based in part on Mok’s “run-time 
scheduler” as described in [Ref. 12: pp. 5-17]. It provides the code for allocating re- 
sources In response to requests generated at run time, c.g. hardware or operator inter- 
rupts, and its scheduling decisions will not be dependent upon prior knowledge of future 
request times for processes to be executed. Tlie specific functions it performs are de- 
scribed below. 

1. THE RUN-TIME EXECUTIVE FUNCTION 

At the start of prototvpe execution, the run-time executive function will invoke 
a procedure called PRELOADER for the translator. PRELOADER 1s a buffer initial- 
ization process required for implementation of PSDL data streams. The translator re- 
quires this process because buffers are regarded as “state machines” and must contain a 
certain value or be in a certain “state” at the start of prototype execution. 

The static scheduler decomposes the prototype into a set of time critical and 
non-timne critical operators. The result of this decomposition are files or “queues” of 
Operators which are the input for the static schedule or the dynamic schedule. The 
run-time executive function will also invoke (start) the execution of the static schedule 
oe its created. 

The schedule for time critical operators is based on the precedence relationships 
among the operators, and on the prototype's real-time constraints. The static scheduler 


creates a schedule that will ensure that both of these requirements are met. One of the 
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scheduling approaches it uses to accomplish this is a blocking strategy similar to the 
method employed by Mok’s Kernelized Monitor Model. 

In the formulation of the static schedule, the static scheduler assumes worst case 
rather than average case processor utilization for meeting a given operator’s processing 
requirements. The scheduling blocks will also contain periods of time between operators 
in which nothing is scheduled in order to ensure that precedence relationships are 
maintained (i.e. data flow requirements are met). These two conditions result in idle 
processing time that can be used by the dynamic scheduler to schedule and execute the 
prototype’s non-time critical operators. The resulting spare processing capability will 
therefore occur unpredictably as shown by Figure 5 on page 26. It is then up to the 
dynamic scheduler to schedule non-time critical processes into these idle areas of the 
static schedule. This idea is similar to the “swapping” methodology emploved by the 
'ED-PP' algorithm, and the “time-division multiplexing” approach within the rate 
monotonic algorithm. 

2. THE CREATE NON-TIME CRITICAL OPERATOR SCHEDULE 
FUNCTION 

When idle processing time is available for use by the dynamic scheduler, the 
Steps illustrated by Figure 6 on page 27 will take place. The static scheduler will attempt 
to “rendezvous” with the dynamic scheduler in order to indicate or “send the message” 
that processing time (a “time shice”) is available. This process is based on the “receiver- 
initiated” (poll-when-idle) strategy, and on the concepts of “inter-task communication” 
and “dispatcher” modules as described in the discussion of dynamic scheduling algo- 
rithms for distributed svstems. 

The dynamic scheduler must then determine (i.e. perform a compare operation) 
if there is enough time available in the time slice to execute a non-time critical process 
before the next scheduled start time of a time-critical scheduling block. This compare 
Operation is analogous to an operation performed by the BEValue2 algorithm of thie 
tume-driven scheduling model. Recall that this algorithin makes a determination as to 
whether or not a given process will overload the processor. Similarly, the dynamic 
scheduler should determine whether or not a non-time critical process can be successfully 
executed within a given amount of time. If this is not possible, the process won't be 
scheduled. When there is enough time available, operators will be scheduled using one 


of the basic principles of the rate-monotonic algorithm. That is, an operator with the 
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shortest execution time will be considered to liave the highest priority and will be 
scheduled for execution first. 

This “priority” assignment 1s an arbitrary one since the processes to be executed 
are not time critical. The logie of this approach 1s simply to schedule as manv non-time 
critical processes as possible into a “block” of idle time and it 1s based on the following 
assumptions: 


l. Employment of a more complex scheme such as the creation of a “value density 
schedule”, is unnecessary and would not effectively contribute to allotment of 
processing resources among the non-time critical processes. 


to 


Processes are independent of one another (i.e. there are no precedence relationships 
among the operators). 


3. An execution time must be assigned to cach of the operators during the specilica- 
tion phase of prototype development. The assigned execution time should not be 
confused with a “timing constraint”, 1t is only meant to provide an estimate of the 
resources required for the execution of a non-time critical process. 
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Figure 6. CREATION AND EXECUTION OF THE DYNAMIC SCHEDULE 


4. Non-time critical processes will be sequenced in the “operator queue” based ona 
“shortest first” scheme. This sequencing will be performed by the static scheduler 
during the prototype decomposition operation. 

For as long as time remains in an unused portion of the static schedule, the 
dynamic scheduler can schedule non-time critical processes for execution based on the 
preceding assumptions. When there is not enough time available to schedule the oper- 
ator at the top of the queue (the operator with the shortest processing requirement), the 
dynamic scheduler will go into a 'wait' state and allow the processor to remain idle until 
the start of the next static scheduling period. Allowing idle tirne in this instance is based 
on the idea of a “forbidden region” in the Kernelized Monitor Model. This forbidden 


region is necessary in order to ensure that a future deadline of the static schedule can 
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be met. Allowing this idle time when using a rate inonotonic approach also makes sense 
from a performance standpoint since utilization related research has indicated that 
processing efficiency tends to decline for processor loads above In 2 (approximately 
70%). 

Even though a “compare” operation 1s perforined to determine whether or not 
an operator can be completed within a given amount of time, the case may arise when 
a non-time critical process may exceed this amount of time. This cannot be allowed to 
occur since it would interfere with the static schedule and in effect, meeting the require- 
ments of the system's real-time constramts. Therefore, execution of the non-time critical 
process must be preempted by some type of monitor. 

The monitoring operation created to do this should track the status of an exe- 
cuting process relative to a system clock, and will terminate (preempt) a process in order 
for the next scheduling block within the static schedule to begin. When a process is 
terminated, it will be returned to the proper sequence position in the operator queue so 
that ıt can be rescheduled at another time. This monitoring process will also perforin 
status monitoring with regard to completion of an operator i.e. it will “notify” the 
compare operation that the execution of a process is complete so that an attempt can 
be made to schedule another process. Finally, the monitor will call exception or inter- 
rupt handling procedures when the execution of a non-time critical process results in one 
of these two conditions. 

3. THE TERMINATE PROTOTYPE FUNCTION 

When exceptions occur as a result of processing performed by any of the three 
CAPS components, the terminate prototype function will be called. This function will 
perform the operations necessary to terıninate the execution of the entire prototype. c.g. 
terminate whatever processes are executing at the time the exception occurs, and notify 
the CAPS user that an exception of a certam ty pemias cectnaa: 

4. THE HANDLE INTERRUPTS FUNCTION 

Two types of interrupts can occur while a prototype is executing, an operator 
interrupt and a hardware interrupt. Depending upon the nature of the interrupt, this 
function will call the terminate prototvpe function or it will initiate some other appro- 
priate interrupt handling procedure. For example, in the instance of a hardware inter- 


rupt, instructions to go to a particular hardware address could be executed. 
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B. THE USE OF ADA 

The dynamic scheduler will be implemented in Ada® as previously described. Ap- 
pendix D provides a “skeleton” program based on the Ada® language in order to show 
some of the features of the language which are relevant for this implementation. For 
example, it demonstrates the use of an Ada® procedure. Recall that an Ada® procedure 
is a fundamental programming unit that encapsulates a series of statements. 

This program also demonstrates the use of a task. A task in Ada® is based on the 
concept of communicating sequential processes. Tasks can be viewed as independent, 
concurrent operations that communicate with one another by passing “messages” [Ref. 
5: pp. 68, 70]. This feature is particularly important to the CAPS execution support 
system as mentioned earlier because ıt provides the means for communication among 
each oi: the three CAPS components. 

Another feature of the language included in this program is the instantiation of the 
generic package CALENDAR. CALENDAR has a predefined function, CLOCK that 
returns the time of dav and exports a data tvpe of time. This package provides a simple 
yet effective means for monitoring the execution time of an operator. 

One other aspect of Ada? illustrated in Appendix D is an exception handling pro- 
cedure. The Ada® language contains several predefined exceptions, and it also provides 
a user with the ability to define exceptions for a given application. For the CAPS, these 
Beewecciined exceptions will be be the predefined PSDL exceptions (e.g. 
DER BUFFER, EMPTY BUFFER). 

An exception 1s handled within the program unit where it is created (via a raise 
Statement), or it can be sent (propagated) to another unit for handling. Since the dy- 
namic scheduler is considered to be the run-time executive for the CAPS execution sup- 
port system, it makes sense from an efficiency standpoint to handle exceptions at this 
“central” location within the execution environment. 

The “centralization of control” logic also makes sense for the the handling of inter- 
rupts. Although not shown by the skeleton program. interrupt handling procedures can 
include an Ada® representation clause which allows the use of machine-dependent facil- 
ities. For example, an Ada® representation clause of the form “for FAIL use at 
16F1FES” as illustrated by [Ref. 3: p. 308] can be used. The hexadecimal number 
l0S [FEF represents some hardware or vector address. 

One last language feature which should be mentioned, is a possible “file” structure 


for storing the non-time critical operators. Recall that this file (the “operator queue’) 


ıs one of the results of the prototype decomposition performed by the static scheduler. 
Several different structures could be used depending upon which would provide the most 
effective means for performing input and output operations on processes during dynamic 
scheduling. One structure which is often used in Ada® to hold sorted data is a binary 
tree as illustrated by [Ref. 17: p. 150]. Other file structures which could be used include 
a linked list or a data stack. Implementation of any of these would allow the dynamic 


scheduler to perform the input/output operations required by its design. 


IV. SUMMARX 


A. THE QUESTIONS ANSWERED 


This study attempted to meet two objectives: 


1. Conceptual development of a dynamic scheduling component for the computer- 
alded design system CAPS 


2. Interface of the dynamic scheduling component with the other two components of 
the CAPS execution support system 


The focus on these objectives has resulted in the conceptual development of a four 
function dynamic scheduler. This design as outlined by Appendix C, demonstrates how 
the dynamic scheduler will interact with the translator and the static scheduler conipo- 
nents within the CAPS execution support environment. Further, the scheduling ap- 
proach proposed for the scheduling of a prototype's non-time critical provides a viable 
alternative for inaking effective use of idle processing resources that occur as a result of 


ensuring that a system's real-time constraints are met. 


B. THE PROBLEMS THAT REMAIN 

Future research for the CAPS dynamic scheduling problem needs to address several 
areas. An area of primary importance 1s a more detailed development of the couceptual 
design, including an examination of its feasibility given the assumptions its based on. 
Special attention should be placed on developing a more detailed description of the op- 
erations required for the “Create Non-time Critical Operator Schedule” function. Once 
this process is complete, the Ada® coding required to iunplement the dynamic scheduling 
functions can proceed. 

Another area which needs to be addressed is the development of a “debugger” 
function for the dynamic scheduler as proposed bv IRef. IS) and (Ref. 2: p. 9]. The 
purpose of the debugger is to collect statistics on prototype behavior and to accept 
control of prototvpe execution when a PSDL exception occurs. (Recall that the initial 
dvnamic desigi1 merely terminates prototype execution). The addition of this function 
would enhance, and at the same time, possibly reduce the number of iterative phases 
required during prototype development because of the additional control and informa- 
tion it provides to the designer. 

The debugging function can be fairly conventional. For example, the abilitv to at- 


tach breakpoints to operators, which can be conditional with respect to a PSDL predi- 
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cate (an “1£” condition) could be included. Selected inputs or outputs of an operator 
should be traceable, resulting in a display of the valucs and their associated arrival or 
departure times. Commands for inserting and deleting values in data streams should 
also be provided. 

The facilities for gathering statistics should include commands for monitoring both 
frequencies and timing information. Frequency statistics include the number of values 
that pass down a data stream, the number of times an exception occurs, etc. Timing 
statistics include nunimum, average, standard deviation, and maximum times for the 
execution, response, or intervals between firings of an operator. These statistics are in- 


tended primarily for feasibility and performance studies. [Ref. 19: pp. 10 -13] 


C. CAPS: AN EFFECTIVE DEVELOPMENT ALTERNA 

An example of an effort that would derive substantial benefit from the use of CAPS 
is the software development required for implementation of the Defense Switched Net- 
work (DSN). The implementation strategy that will be employed requires components 
and features to be adopted gradually, beginning with an initial capability based on to- 
dav's voice network (Ref. 20: p. 11]. 

The DSN ıs the future Command and Control (C2) telecommunications network for 
the U.S. strategic armed forces. It is being designed to provide rapıd, endurable, and 
economical teleconimunications services to both high and low prroritv users. Iligh prl- 
ority users require immediate (1.e. real-time) Service under the most difficult nussion 
stress conditions. Low priority users require service for performing operational support 
activities such as logistics and personnel related functions which are not subject to the 
same type of real-time constraints. In order to meet these requirements, the network ts 
planned to include more than 200 U.S. Government-owned communications switches in 
Europe and more than 60 U.S. Government-owned switches in the Pacific, as well as 
commercially leased switching and transmission services in the Western-Henusphere and 
Kaya Rel 202026) 

Comprehensive computer support that is highly reliable from both a security and a 
survivability standpoint, will be required to maintain control of this vast network. This 
computer support will assist in performing these network functions: 

[. monitoring and surveillance to detect performance abnormalities automaucally 
2. implementing real-trme controls that prevent switch or network congestion 


3. analyzing traffic data to permit continuous optimal operation of the network 


Computer aids that minimize personnel requirements will also be emploved--locally 
and from remote locations--in administration, operations, maintenance, and network 
management of network elements. [Ref. 20: p. 6] 

This diverse set of requirements illustrates why this development effort would be 
significantly enhanced by using CAPS, its prototyping methodology, and PSDL. This 
is especially true if the computer support systems are developed using Ada® as currently 


planned. 


D. CONCLUSION 

A primary advantage of CAPS for system development is that PSDL use for con- 
struction of an executable prototype would be much easier and simpler than direct use 
of Ada®, Additionally, executing a prototype (or prototypes) that demonstrates the 
functioning and interaction of modules within a complicated embedded systein like the 
DSN, would significantly increase the confidence that the system can be built as 
planned. Using a prototype would also improve cost estimates since the cost of the in- 
tended system is generally proportional to the cost of a rapid prototype. [Ref. 19: p. 12] 

The conceptual development of the CAPS dynamic scheduler represents a significant 
step forward in meeting the demand for rapid development of reliable software for large 
real-time computer systems. Additionally, the proposed “shortest first” scheduling al- 
gorithm used by the dynamic scheduler could be effective for scheduling non-time critical 
processes in other real-time environments as well. This scheduling approach could prove 
to be an effective way for utilizing idle processing resources which are often wasted in 


large real-time systems. 
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APPENDIX A. A PSDL PROTOTYPE 


This is an example of a PSDL prototype as it appears in [Ref. 4: pp. 27-40]. It was 


developed to model a simple system for treating brain tumors using hvperthermia. 


OPERATOR brain_tumor_treatment_system 
SPECIFICATION 
INPUT patient chart: medical historv, 
treatment switch: boolean 
QUTPUT treatment finished: boolean 
STATES temperature: real 
INITIALLY 37.0 
DESCRIPTION 
(The brain tumor treatment system kills tumor cells 
by means of hyperthermia induced by microwaves. 


END 


IMPLEMENTATION 
GRAPH 


100 
SINULATED_PATIENT 


TEMPERATURE TRERTNENT_POUER 









PATIEMT CHART 
TRERTĦEĦT. SUITCH 


Y HYPERTHERNIA_SYSTEN 


Z TREATMENT _F IMI SHED 


DATA STREAM treatment_power: real 
CONTROL CONSTRAINTS 
OPERATOR hyperthermia_system 
PERIOD 200 BY REQUIREMENTS shutdown 
OPERATOR simulatea_patient 
PERIOD 200 
DESCRIPTION (paraphrased output} 
END 


TYPE medical_history 
SPECIFICATION 
OPERATOR get_tumor_diameter 
SPECIFICATION 
INPUTS patient_chart: medical_history, 
tumor_location: string 
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OUTPUTS diameter: real 

BAGEETIONS ne tumor 

MAXIMUM EXECUTION TIME 5 ms 

DESCRIPTION 

(Returns the diameter of the tumor at a given location, 
produces an exception if no tumor at that location. 


END 


KEXWORDS patient charts, medical records, treatment records, 
lab records 
DESCRIPTION 
{The medical history contains all of the disease and 
treatment information for one patient. The operations 
for adding and retrieving information not needed by 
the hyperthermia system are not shown here. 


END 


IMPLEMENTATION 
tuple {tumor_desc: map-from: string, to: “real{, ... } 


OPERATOR get_tumor_diameter 
IMPLEMENTATION 
GRAPH 





PATIENT_ZCHART 





TUPLE . GET_TUNGR_DESC 





TUMOR_LOCAT 10m ĦU EB 


DATA STREAM td: tumor_descr 
CONTROL CONSTRAINTS 

OPERATOR map. fetch 

EXCEPTION no_tumor IF not(map.has(tumor_location, td)) 
END 


END 


OPERATOR hyperthermia_system 
SPECIFICATION 
INPUT temperature: real, patient_chart: medical_history, 
treatment_switch: boolean 
OUTPUT treatment_power: real, treatment_finished: boolean 
MAXIMUM EXECUTION TIME 100 ms 
BY REQUIREMENTS temperature_tolerance 
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MAXIMUM RESPONSE TIME 300 ms 
BY REQUIREMENTS shutdown 
KEYWORDS medical_equipment, temperature_control, 
hyperthermia, brain_tumors 
DESCRIPTION 
(After the doctor turns on the treatment switch, the 
hyperthermia system reads the patient's medical record 
and turns on the microwave generator to heat the tumor 
in the patient's brain. The system controls the power 
level to maintain the hyperthermia temperature of 
42.5 degrees C. for 45 minutes to kill the tumor cells. 
When the treatment is over, the system turns off the 
power and notifies the doctor. 


END 
IMPLEMENTATION 

GRAPH 
90 

TEĦPERATURE ĦAINĦTAIĦ 
30 

PATIENT. CHART START UP TREATMENT_S 1911 SHED 
10 
TREATMENT. SUITCH SAFETY CONTROL TREATMENT. POLHER 


DATA STREAM estimated power: real 
TIMER treatment. time 
CONTROL CONSTRAINTS 
OPERATOR start. up 
TRIGGERED IF temperature < 42.4 
BY REQUIREMENTS maximum_temperature 
STOP TIMER treatment_time 
RESET TIMER treatment_time IF temperature <= 37.0 


OPERATOR maintain 
TRIGGERED IF temperature >= 42.4 
BY REQUIREMENTS maximum_temperature 
START TIMER treatment_time 
BY REQUIREMENTS treatment_time, temperature_tolerance 
OUTPUT treatment_finished IF treatment_time >= 45 min 
BY REQUIREMENTS treatment_time 


36 


END 


OPERATOR start_up 
SPECIFICATION 
INPUT patient_chart: medical historv, temperature: real 
QUTPUT estimated power: real, treatment, finished: boolean 
BY REQUIREMENTS startup_time 
MAXIMUM EXECUTION TIME 90 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 
(Extracts the tumor diameter from the medical history and 
uses it to calculate the maximum safe treatment power. 
Estimated power is zero if no tumor is present. The 
treatment finished is true only if no tumor is present. 


END 


IMPLEMENTATION Ada start_up 
END 


OPERATOR maintain 
SPECIFICATION 
INPUT temperature: real 
OUPUT estimated_power: real, treatment_finished: boolean 
MAXIMUM EXECUTION TIME 90 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 
{ The power is controlled to keep the power between 42.4 
and 42.6 degrees C. 


END 


IMPLEMENTATION Ada maintain 
END 


OPERATOR safety_control 
SPECIFICATION 
INPUT treatment_switch, treatment_finished: boolean 
estimated_power: real 
OUTPUT treatment_power: real 
BY REQUIREMENTS shutdown 
MAXIMUM EXECUTION TIME 10 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 
{The treatment power is equal to the estimated power 
if the treatment switch is true and treatment finished 
is false. Otherwise the treatment power is zero. 


END 


IMPLEMENTATION Ada start_up 
END 
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APPENDIX B. PSDL GRAMMAR SUMMARY 


This is a summary of PSDL grammar and language conventions as initially de- 
scribed ın [Ref. 1: pp. 54-56] and further refined by [Ref. 6]. Several conventions are 
used for symbology in the grammar. [ Square Braces ] indicate optional items. { Curly 
Braces } indicate items which may appear zero or more times. Bold face type indicates 
a named terminal symbol which must appear in the program listing the programmer 
writes. “Double quotes” indicate character literals which must appear in the program 


a 


listing. The vertical bar indicates an exclusive-or selection. In this case the pro- 
grammer selects one and only one of the iterns separated by the vertical bar. 

As an example, the token timing_info is one of six mutually exclusive possibilities 
which may define the attribute token. The attribute token may appear zero or more 
times to define the tnterface token, which ts a required attribute of the operator_spec 
token. Timing info, if selected for attribute, may be empty, or it may contain one or 
more of the optional tokens allowed to define timing info. Each of these tokens may 


appear no more than one time for a given instance of tinung_info. 


psdl = { component } 


coinponent = | data_type 
| operator 


data type = type id type spec type Impi 

operator = operator id operator spec operator_impl 

tvpe_spec = specification [type _decl] {op_spec_list} [functionality] end 
op_spec_list = operator id operator_spec 

operator spec = specification interface [functionality] end 


interface = {attribute f{reqmts_tracc]} 


— eee ——— 


attribute = | generic_param 
Input 

output 

states 
exceptions 

| timung info 


generic_param = generic tvpe decl 
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input = input type decl 

output = output type_decl 

states = states type_decl initially expression list 
exceptions = exception id_list 

ist 7 id-47, id} 


timing info = [maximum execution time time] 
[minimum calling period time] 
(maximum response time time] 


time = number [unit] 
unit = | microsec | ms | sec | min | hours 


reqmts_ trace = by requirements id_list 


functionality [keywords] [informal desc] [formal desc] 
keywords = keywords id list 
informal_desc = description 7(7 text “)” 

u ae 


formal desc = axioms “(” text 7) 


type imp] = | implementation Ada id 
| implementation type_name ( op_impl list } end 


op_impl list = operator id operator_impl 


Operator impl = | implementation Ada id 
| implementation psdl impl 
psdl impl = data_flow_diagram 
[streams] 
[timers] 


[control_constraints] 
[Informal desc] 
end 


data flow diagram = graph (link) 

link = id ".” opid "->" id 

opid = td [ ”:” time] 

streams = data_stream type decl 

mupendeci — id list 11 type name [(“,” id list “:” type name ) 


tvpe name = lid 
[id “[° type _decl T 


timers = timer id_list 
control_constraints = control constraints { constraint } 


constraint = operator id 
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[triggered [trigger] [F predicate] [reqmts trace] |] 
(period time [reqmts trace] ] 

{finish within time [reqmts_ trace] | 

(output id list if predicate [reqmts_trace] } 
(exception id {if predicate] [reqmts_trace] } 

(timer Op id {if predicate] {reqmts trace] } 


timer op = | start | stop | read | reset 


trigger = | by all id_list 
| by some id list 


predicate = | not predicate 
| predicate Vand earccdicare 
| predicate or predicate 
expression. list 
lid “:” id list 


expression list = expression £ 7,7 expression) 





expression = | number 


| constant 
| id 
| type maine. id “(" expressionalist am 
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APPENDIX C. DYNAMIC SCHEDULER FUNCTIONS 


1.0 Run-Time Executive 


1.1 Invoke Translator Preloader Procedure 
1.2 Invoke Static scheduler 
2.0 Create Non-Time Critical Operator Schedule 


2.1 Compare Time Slice to Operator Queue Time Requirement 
2.1.1 Find top of queue (operator with shortest 
time requirement) 


2.1.2 Subtract operator time requirement from time slice 

2.1.3 When result of subtraction > 0, send time 
available message to execute operator function 

2.1.4 When result of subtraction < 0, let processor 


idle until start of next static schedule 


requirement 
2.2 Schedule Operator 
2.2.1 Schedule available operator from operator 
queue for execution 
2.2.2 Send completion message to monitor 
2.2.3 Send exception message to monitor 
2.2.4 Send hardware/interrupt message to monitor 


2.3 Monitor Process 

2.3.1 Monitor execution time of operators 

2.3.2 Terminate operator if available 
processing time is exceeded 

2.3.3 When operator completes execution, 
send message to compare operation 
to see if more execution time is 
available 

2.3.4 When exception occurs during dynamic 
schedule processing, call terminate 
prototype function 

2.3.5 When interrupt occurs during dynamic 
schedule processing, call handle 
interrupts function 


3.0 Terminate Prototype 
3.1 Terminate Translator 
3.2 Terminate Static Scheduler 
3.3 Terminate Dynamic Scheduler 


4.0 Handle Interrupts 
4.1 Send terminate request to terminate prototype 
4.2 Send non-terminatable request to appropriate 
location 


4] 





APPENDIX D. PSEUDO-CODE FOR AN ADA PROGRAMI 


This pseudo-code illustrates some useful features of the Ada® programming lan- 


guage (Ada® is a registered trademark of the United States Government, Ada Joint 


Programming Office). A detailed description of how these features can be implemented 


in an Ada® program appears in [Ref. 5] 


--Two hyphens indicate the start of a comment in the Ada language. 
--Four hyphens within this pseudo-code are used to enhance 
--readability and to indicate the absence of formal 

--parameters, statements, or other features of the language 
--that are required by an actual program 


with OPERATOR_QUEUE; 


with CALENDAR; 


--the operator queue of 


--non-time critical processes 
--will be created by the 
--static scheduler 


--the Ada language definition 
--includes the package CALENDAR 
--with a predefined function, 
--CLOCK that returns the time 
--of day and exports a data type 


--of time 


procedure DYNAMIC_SCHEDULER is 


declare 


HULL BUFFER: 
EMPITY_ BUFFER: 
OVER TIME: 


PSDL EXCEPTION: 


exception; 
exception; 
exception; 
exception; 


--when an exception is 
--raised within an Ada 
e program unit.: it is 
--propogated to a level 
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--where it can be handled 


type READY is text; --the text types indicate the 
type SCHEDULE is texts --different messages exchanged 
type TIME SLICE is text; --during a rendezvous 

PRELOAD : READY; 

SCHEDULE : ‘CREATED: 

IDLE 2 LIMESS Eick. 


procedure PRELOADER; --PRELOADER will be some actions 
--that will invoke buffer 
--initialization procedures for the 
--translator 


procedure START; --START will consist of some actions 
--to start the execution of the 
--static schedule 


procedure CREATE_SCHEDULE is --the procedure that will 
--create a schedule for 
--the non-time critical 
--operators 


use CALENDAR; 
use OPERATOR_QUEUE; 


TIME, OPERATOR_TINE_REQUTREMENT Gite Eick. 


begin 


- -COMPARE_OPERATION 


de 


--find top of OPERATOR QUEUE (operator with shortest 
--time requirement) 


--select this operator and compare its execution 
--time with TIME_SLICE in order to determine 
--if enough time is available to 

--execute this non-time critical process 


--while enough time is available, in a given 
--TIME_SLICE, schedule processes for execution 


--else let the processor idle till start 
--of next static scheduling block 


-~ æ =] um 


--MONITOR_PROCESS --implement a process to monitor 
--status of executing non-time 
ssetitical operators (tame, completion, etc. ) 
--using the generic package CALENDAR 


end CREATE_SCHEDULE; 


— w æ 


task RUN_TIME_EXECUTIVE is --an Ada task is an effective 
--method for implementing the 
--the run-time executive function 
--because it provides a means for 
--communication among the three 
--execution support system commponents 


--entry and accept provide the 
--means for "two way" 
--communications among the three 
--execution support system components 


entry TRANSLATOR (PRELOAD : in READY); 


--the communications path from 
--the dynamic scheduler 

--to the translator which will be 
--used to invoke the buffer 
--preloader procedure 


entry STATIC_SCHEDULER (SCHEDULE : in CREATED); 
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--the communications path between 
--the dynamic scheduler and the 
--static scheduler which will be 
--used to invoke (start) the 
--execution of the static schedule 


entrv IDLE TIME (IDLE tin TESLE 


--the communications path between 
--the dynamic scheduler and the 
--static scheduler which will be 
--used to indicate to the dynamic 
--scheduler when idle time is 
--available 

end; 


.2 = æ a 


task body RUN_TIME_EXECUTIVE is 


begin 


= m e A 


accept TRANSLATOR (PRELOAD : in READY) do PRELOADER; 


--PRELOADER will be some actions that 
--will invoke buffer initialization 
--instructions 


accept STATIC_SCHEDULER (SCHEDULE : in CREATED) do START; 


--START will consist of some actions 
--to start the execution of the Stat 
--schedule 


accept IDLE_TIME (IDLE : in TIME SLIĊE) do GREATESSCHEDURE 


--when idle time is available, the 
--dynamic scheduler can schedule 
senon-time critical processes on 
--execution during a given 

-- time slice: 
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end RUN_TIME_EXECUTIVE; 


begin 


RUN TIME EXECUTIVE. TRANSLATOR (PRELOADER); 
RUN TIME EXEGUTIVE. STATIC SCHEDULER (START); 


RUN TIME EXECUTIVE. IDLE TIME (CREATE SCHEDULE); 


--when an exception occurs, the generic procedure TEXT IO 
--and an application specific procedure such as PUT_LINE 
--can be used indicate to the CAPS user what the nature 
--of the exception is 


exception 
when FULL_BUFFER=> 


TEXT_IO. PUT_LINE ("An attempt was made to 
updatea full pufrer ); 
TERMINATE PROTOTYPE; 


--using the Ada generic package TEXT_IO, 
--and a user written procedure PUT_LINE, 
--a message as shown will appear on the 
--user's screen and prototype execution 
--will be terminated when an exception is 
--raised. 

end; 


exception 
when EMPTY_BUFFER=> 


TEXT_IO. PUT_LINE ("An attempt was made to 
read data from an empty 
Butter, 

TERMINATE PROTOTYPE; 
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end; 


exception 
when OVER_TIME=> 


TEXT_IO. PUT_LINE ("A PSDL operator has 
exceeded maximum 
execution time’); 

TERMINATES PROLOG Pye 


end; 


exceptioi 
when PSDL_EXCEPTION=> 


TEXT_IO. PUT_LINE ("An undefined PSDL 
exception 
has occurred"); 
TERMINATE ZROTOTYPE; 


end; 


end DYNAMIC_SCHEDULER; 
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